Master-Slave Architecture

Master-Slave Replication (also called Primary-Secondary) is a design pattern where one node (master/primary) handles write operations, and one or more slave/secondary nodes replicate the data and serve read operations.

It is commonly used in databases, file systems, caches, and message brokers to improve scalability, read performance, and fault tolerance.

Key Concepts of Master-Slave

Concept	Description
Master (Primary)	The node that handles all write operations and propagates updates.
Slave (Secondary)	One or more nodes that replicate data from the master and serve reads.
Replication	The process of copying data from master to slave (sync or async).
Failover	A mechanism to promote a slave to master in case the master fails.

How it works

1. Client writes data to the master.
2. The master stores the data and logs the changes.
3. Slaves pull or receive changes from the master (depending on the replication mode).
4. Clients read data from slave nodes (or optionally from the master).

Replication Modes

Mode	Description
Synchronous	Master waits until slaves confirm the write. Strong consistency.
Asynchronous	Master writes immediately; slaves update later. Faster but can lag.
Semi-synchronous	Master waits for one slave to confirm. Balance between consistency and performance.

Example: MySQL Master-Slave Setup

Let’s consider an e-commerce application using MySQL:

• Master MySQL node: receives all INSERT, UPDATE, and DELETE operations.
• Two Slave nodes: replicate changes from the master using binary log (binlog).
• The app:
  • Sends writes (e.g., orders, user registrations) to the master.
  • Sends reads (e.g., product catalog, order history) to the slaves.

Flow Example

1. User places an order.
2. API server writes the order to the master DB.
3. Master writes to disk and appends to binlog.
4. Slave DBs read the binlog and replicate the change.
5. User checks order history — the app reads it from a slave DB.

Diagram

                          +-------------+
                          |   Clients   |
                          +------+------+
                                 |
                +-------------------------------+
                |         Load Balancer         |
                +-------------------------------+
                   | Write (INSERT/UPDATE/DELETE)
                   v
           +------------------+         +------------------+
           |   Master (DB)    | ----->  |   Slave (DB)     |
           |  Writes + Reads  |         |    Read-only     |
           +------------------+         +------------------+
                                              |
                                          +------------------+
                                          |   Slave (DB)     |
                                          |    Read-only     |
                                          +------------------+

Tools that Use Master-Slave

System	Role
MySQL/PostgreSQL	Native support for master-slave replication
Redis	Supports primary-replica setup for caching
MongoDB (legacy)	Before replica sets, Mongo used master-slave
Kafka	Topic partitions have a leader (master) and ISR followers
HDFS	NameNode (master) and DataNodes (slaves)

Pros and Cons of Master Slave

✅ Pros	❌ Cons
Scales reads horizontally	Writes are not scalable (bottleneck at master)
Enables fault tolerance (with failover)	Replication lag in async mode
Allows backup without impacting master	Failover handling is complex
Can replicate to remote locations	Master is a single point of failure (unless managed)

Compared to Multi-Master

Feature	Master-Slave	Multi-Master
Write Scaling	Only master handles writes	All nodes can write
Consistency	Easier to ensure consistency	Harder (conflict resolution needed)
Complexity	Simpler	More complex
Example Use Case	Traditional SQL, Redis, analytics	Collaborative apps (e.g. Google Docs)